I wrote this cdev mainly because I was tired of having to (a) browse through my System Folder looking at file names or (b) use ResEdit on the QuickTime init, just to see what the heck kinds of things (er, excuse me, components) I had lying around my system. Anyway, Things! mainly just queries the Component Manager about what IT thinks is lying around your system, and then displays the info for you.
Things! will not show up in your Control Panel (or alternatively, will not launch under System 7) if (a) the Gestalt call is not available (meaning you're running a fairly old system), (b) the Component Manager is not installed, or (c) the Component Manager version is not recent enough (you shouldn't hit this one for a while - the Component Manager has been at version 1 for quite some time). Also, the cdev is rawther lahge at the moment (~190Kb) - this is mostly due to a boatload of debug code that's getting carried along, which I'm keeping in for awhile.
Note of interest: Things! can only find components that are (a) registered globally or (b) are registered in its A5 world. It won't find components that are registered locally to A5 worlds other than the one it lives in. Also, if you edit a component that is in the same A5 world that the Things! cdev lives in, Things! will register this component back globally, whether it was originally registered that way or not. I don't currently have a way to tell whether or not a component is registered locally or globally, so I assume if I can see it, it must be global.
This cdev is mainly intended as a utility (read that, hack) for QuickTime developers, although I've been told it's mildly interesting to non-engineering types, too - it never hurts to be aware of what's going on in your system!
--------------------------------
Minimum required configuration:
Component Manager version 1
System 6.0.7 or later
--------------------------------
Tested configurations:
Mac Quadra 900, 24Mb RAM, running 7.0.1 and QuickTime 1.0
Mac IIfx, 80 Mb RAM, running 6.0.7 and QuickTime 1.0
Mac IIfx, 80 Mb RAM, running 7.0.1 and QuickTime 1.0
Mac IIci, 8 Mb RAM, running 7.0 and QuickTime 1.0
Mac II, 8 Mb RAM, running 7.0 and QuickTime 1.0
--------------------------------
Known bugs:
1.0d1
- The cdev occasionally bus-errored if you clicked back and forth between two components in the name list long enough. I think this was due to a bad memory dereference (handle wasn't locked), and should be fixed in 1.0d2.
1.0d2
- The type list occasionally loses some types after a "Destroy" or a name or info edit (sometimes this is OK, for example, if you just destroyed the last component of a given type). Just close the cdev and re-enter it and everything should be jake. I'm working on finding out what's going on with this.
- When Things! is in the background, and components are registered/unregistered, sometimes it gets confused (this is definitely MY fault - I need some additional checks on my lists). Same story as above; just leave and re-enter and stuff is OK.
- Back to back edits on the same field (name or info) on the same component usually screws up the name list. Same story as above; just leave and re-enter and stuff is OK.
- Using cut/paste/copy/clear command keys appends the key character (for example, "X" for Cut) in the text edit field. Using the menu for these commands works fine.
1.0d3
- Doesn't run on 68040 machines.
1.0a1-1.0a2
- Doesn't handle non-resource based components (assumes all components have a resource file - BAAAAD assumption). Crashes quite nastily when it encounters such a component.
--------------------------------
Version history:
1.0d1 6/10/91
- First release
1.0d2 7/28/91
- Changed cdev so that it will update its information on update or idle events (it checks the component list mod seed to see if this is necessary). This allows the cdev to pick up registrations/unregistrations of components that occur while it is not the active window (sort of like a component monitor). This is sorta working.
- Changed name list to highlight the default component for the selected type when the name list is drawn.
- Name field can now be edited by option-clicking on it. Cut, copy, paste, and clear are supported, but undo is not yet implemented, so BE CAREFUL. A note: If the component does not have a 'thng' resource, or if there are currently instances of the component, editing will not be enabled (big surprise). Editing is terminated by clicking anywhere outside the edit box, or by hitting the return or enter keys.
- Put in paging code; the cdev now has a number of "pages" on the bottom third of the display. Paging is controlled by the left and right arrow buttons at the top left of this area, or by using the left and right arrow keys on the keyboard. The various pages are described below.
Page one: Displays the component info. Option-clicking on this field will allow standard text editing, including cut, copy, paste, and clear. Editing is terminated by clicking anywhere outside the edit box, or by hitting the return or enter keys. Note that undo has NOT been implemented yet, so BE CAREFUL. A note: If the component does not have a 'thng' resource, or if there are currently instances of the component, editing will not be enabled (big surprise again).
Page two: Displays the component's implementation version and interface version, along with a button ("Set default") to make the currently selected component the default component for that type (unfortunately, this selection doesn't currently get remembered across restarts). If this page was entered with the option key held down, then a second button will be available ("Destroy"); this button allows you to UNCONDITIONALLY unregister a component. BIG WARNING: THIS IS NOT UNDOABLE, except by re-registering the component (this is ordinarily done at startup through auto-registration, although if the component was programmatically created, my guess is you would have to re-launch your app). I would advise you NOT to futz with this control unless you really know what you're doing with respect to components and the Component Manager. If an application that you're currently running is using an instance of the component that you decide to nuke with this control, that application will AT LEAST start issuing all sorts of error alerts/messages, or AT WORST just exhibit extremely unpredictable behavior (including but not limited to crashes and lock-ups). This will happen because when you nuked the component, the application using it generally isn't aware that the component (and its accompanying instance) is no longer valid as far as the Component Manager is concerned; thus, Component Manager calls to this component or ANY calls to its instance will return errors, and what happens next sorta depends on how robust the application's error checking is. I was thinking about qualifying the enabling of this control with a check to see that no instances of the selected component currently exist - I'm still not sure whether to do this or not (opinions?). Now, you're probably wondering, if this control is so NASTY, why even have it around? Well, it turns out to be fairly useful in the development and test of new components; it is NOT intended for casual use. 'Nuff said.
Page three: Displays the state of the component flags and flags mask of the currently selected component. For now, I've got some really cumbersome left/right arrows that let you select the flag you're interested in - I'll get rid of these buttons in favor of something more direct shortly. A description of the currently selected flag (if available) is displayed at the bottom of the page. Point of interest: The flags mask, as defined in the component resource, should be all clear (no bits set). If a bit is set in the mask, you've probably goofed up somewhere (or, alternatively, I've got a weird bug in this cdev…). Also, the flags draw pretty slowly right now - this'll get fixed soon. If the currently selected component doesn't have a 'thng' resource, then I've got no idea what the flags are (since I don't have a 'thng' resource to look at), so basically, you don't see any flags or mask.
Page four: Displays the resource info and attributes of the currently selected component. If the component has no 'thng' resource, you get a bunch of blank spaces.
Page five: Displays version info for the System Software, the Component Manager, QuickTime, and the Compression Manager. If you have only installed portions of the above (for example, you're using the Component Manager init, but not the QuickTime or Compression Manager inits), you should only see version info for the stuff that is installed.
Page six: About box.
- Put in code to show the number of instances of a given type of component and the number of instances of a given component (clicking on the text toggles between the two displays).
- Fixed miscellaneous obscure memory bugs (I hope).
- Put in a System 7 style control panel ICN# resource.
- Added Finder help balloon; others to come as soon as I get around to it.
1.0d3:
-Updated type/subtype/mfg codes.
1.0a1:
-Fixed so that it runs on 68040 machines.
1.0a2 6/8/92
-Updated type/subtype/mfg codes.
--------------------------------
Assumptions:
I assume that the resourceSpecs for the name and info for all components describe Pascal style strings (e.g. 'STR ' , 'STR#', 'TEXT', or make up your own type), and that the resourceSpec for icons are of some normal icon resource type ('ICON', 'ICN#', etc.).
A caveat with respect to editing: It is remotely possible that when you ask Things! to edit the 'thng' resource of a component, it might find the wrong one. Things! goes through a lengthy matching process to find the right component resource for a given component; there is no call in the Component Manager which will return you a component's resource file for write access. [Aside: Before anyone starts griping about this, life is this way because having write access to the component's resources means you can change stuff behind the Component Manager's back, and, in fact, behind the back of any app that's using that component, and serious nasties can subsequently occur. That's why most folks get to play with INSTANCES of a component, rather than the component itself; the component is the pure and pristine template for all its instances, and we wouldn't want to dirty it up by munging it.] Anyway, Things! will make a bad match ONLY if you happen to have two components in the same file with contents of their ComponentResources matching EXACTLY. In other words, the following must match:
- name resource type
- name resource ID
- info resource type
- info resource ID
- icon resource type
- icon resource ID
- code resource type
- code resource ID
- type
- subtype
- manufacturer
Unless you really go out of your way to do this, it's a pretty unlikely situation. The only situation I've been able to dream up where this MIGHT happen is if you were upgrading a component in a file via some kind of script (maybe Installer) and it didn't delete the old component from the file. So, anyway, I'm assuming that no one is going to construct this situation, and life will be jolly. Just thought I'd mention it.
--------------------------------
Stuff to do:
- Add controls to reset the default components for the system (that is, remember somewhere what the defaults were before the user started mucking about, so that if s/he wants to recant, s/he can do so... sounds like a prefs file... )
- Generate a default component prefs file for the Component Manager to read on boot, so that the user's choices for default components are remembered across restarts.
- Change the name list from a text-only LDEF to an icon and text LDEF (a la the Sound cdev); this means you component developers are gonna have to come up with some icons for your components unless you want them to be displayed with the generic 'thng' resource icon
- Add error dialogs where needed
- Add icon replacement capability to name list (after I get icon LDEF put in) that is accessed by option-clicking; also, add cut, copy, paste, clear, and undo for this action.
- Add support for component settings dialogs, which will be accessed by double-clicking on the component name/icon; currently, if you double-click on a component name, you get a bogus place-holder dialog.
- Add undo support for text editing.
- Finish adding help balloons
- Internationalize stuff (this is partially done)
- Put up the right cursor for the action currently taking place (I-beam for text editing, etc.)
- Futz with the interface and layout from time to time
- Fix bugs (kinda goes without saying, I suppose)
--------------------------------
Some stuff I've noticed:
- If a component does not have any resources for name or information, or they provide resources which are empty, I just put up "Untitled component", "(None)" or somesuch meaningless string. Just thought I'd let you know.
- Components which do have information seem to be wildly diverse as to what should go in there. I personally don't care, so don't whack me with the big stick, but is this something that is going to be standardized? If so, what is the standard? (No, I don't work for the HI guys, really!) If not, I will probably keep this field as an editable field, so that folks can put whatever they want into it.
--------------------------------
Final note:
If anyone discerns any errors or inconsistencies in the above ramblings/blatherings/ruminations/etc. on the way of life in the wonderful world of the Component Manager, kindly endeavor to enlighten my humble self (seriously!) - I would, of course, prefer an opportunity to expound on the origins of my misconceptions before being publicly vilified, and, to that end, you will find a means to correspond with me below. (I don't know, sometimes this long-winded stuff just BEGS to get put down on paper…)
--------------------------------
That's it! Have fun, and if you have comments/questions/suggestions/feature requests/bug reports/etc., please send them to me at WOODCOCK.G (AppleLink), and I'll do something (no guarantees as to exactly what that might be, however, since I have REAL work to do besides this!).
